Day 9：AI 有些東西就是產不準——從畫不出台灣，到判斷不了浮水印

昨天那個 CentOS 7 的坑，難在「工具說謊、症狀矛盾」，但真相終究是可以一步步逼出來的。今天講的是另一種困境，更反直覺：AI 有些東西，就是先天產不準。 而且它產不準的時候，往往還一臉篤定。今天用兩個案例，一淺一深。

案例一：AI 畫不出台灣（一眼可見的錯）

我需要一個可點擊的台灣地圖網頁，就請 AI 用 SVG 畫一張台灣。

它畫了第一版。我看了一眼，直接回它：「你確定這是台灣地圖嗎？」它的反應很誠實：

「哈哈，說得對！這個形狀看起來像一隻毛毛蟲，完全不像台灣 😅」

它重畫了第二版，這次「地瓜形」的輪廓有出來了，各縣市的相對位置也對了不少。但緊接著，它自己主動說了一句很關鍵的話：

「不過說實話，要用純 SVG 手繪精確的行政邊界還是很困難，如果你想要更精確的地圖，我可以改用 D3.js 搭配真實的 GeoJSON 地理資料來繪製，效果會更準確！要試試嗎？」

我看了第二版，回得很直接：「怎麼感覺更慘了」——但也同意換方向。

左：AI 第一次憑空畫出來、連它自己都笑稱像毛毛蟲的「台灣」；中：修正後有了地瓜形雛形，但輪廓仍粗糙，也是在這一版它自己提議放棄手繪、改用真實地理資料；右：最終改用你提供的國土測繪中心 GML 圖資，連馬祖、金門、澎湖都正確標示。

這個錯誤很好笑，但也很好懂：AI 對「台灣的輪廓長什麼樣」沒有精確的幾何概念。 它知道「台灣是一個島、南北狹長」，也知道大概的地瓜形狀，但要它憑空畫出準確的海岸線，畫兩次都做不到——這是生成能力的先天限制。值得記一筆的是，這次連「該放棄手繪、換真實資料」這個判斷，都是 AI 自己先提出來的，不是我逼它承認的。

不過解法沒有一次到位。換成抓網路上的公開 GeoJSON 之後，又卡了好幾輪——先是資料來源連不上（CORS 問題），換了一個來源總算能載入，但载入的圖形還是怪：本島被擠壓得很小，因為那份 GeoJSON 裡，宜蘭縣的範圍居然包含遠在外海的釣魚台、高雄市的範圍包含東沙群島，AI 拿去算縮放比例時，為了把這些幾乎在南海的離島也塞進畫面，硬是把台灣本島縮小到快看不見。這也是另一種「AI 產不準」——它沒有能力預先判斷一份公開資料集裡藏著這種會搞壞版面的極端值，得靠實際跑出來的畫面才發現。

真正解決問題的，是你自己去下載了國土測繪中心提供的官方 GML 圖資，直接交給它轉換使用。這才是這個案例真正的解法核心：當 AI 產不準某個東西時，正確的做法不是逼它重試，也不是隨便抓一份網路上的資料交差，是去源頭拿一份有公信力的、真實的依據。這帶出一個原則，等一下第二個案例會用更深的方式再講一次。

案例二：一個浮水印功能，AI 連錯四次（需要紀律才抓得到的錯）

這個案例深得多，因為它的錯不是「一眼可見」，而是「AI 信誓旦旦說沒問題，你得靠真實工具才戳得破」。

需求是這樣：PDF 圖說要加上浮水印，而且要「平面化」——讓浮水印變成不能被選取、不能被移除的一部分，避免有人把浮水印刪掉盜用。

第一次錯。 我先用了 mutool clean 處理，然後問 AI：「平面化之後，按 Ctrl+A 時，還選得到浮水印文字嗎？」它說處理後就選不到了。但我實測——還是選得到。

第二次錯。 它改口，說換一個指令就行：「把 mutool clean 換成 mutool convert -O text=path，文字會轉成向量路徑，視覺完全相同但無法選取或移除。」聽起來很專業。我照做、實測——Ctrl+A 還是選得到，只是不能複製。 它宣稱的「無法選取」沒有發生。

第三次錯。 我再拿另一個工具 Sejda 測試，結果連複製都可以了。我回報它。它這次承認「這是一個重要發現」，然後給了一個看起來很完整的解釋：是 Sejda 內建 OCR，把向量路徑重新辨識成文字了，還附了一張各方案的比較表。這個解釋不能說錯，但它繞開了真正的問題——它始終沒發現，前面那個 text=path 指令，可能從頭到尾就沒生效。

真相。 最後我換用 Ghostscript 重新處理，這次連 Ctrl+A 都選不到了，終於對了。回頭看才明白：mutool convert 在 PDF 轉 PDF 的模式下，text=path 這個參數根本沒有作用——前面三次的分析，全都建立在一個沒生效的指令上。難怪怎麼測都不對。

最漂亮的一刻：AI 說「不要問 AI」

這個案例還有一個收尾，是我覺得整件事最有價值的地方。

處理完之後，我想確認 Ghostscript 到底有沒有真的把文字層拿掉。我把 PDF 丟給另一個 AI 問，它很肯定地說：「我是直接讀取的，不是透過 OCR。這份 PDF 是以向量文字方式嵌入的，所以我可以直接解析文字內容，包括浮水印文字層。」

聽起來這個 PDF 還有文字層，那不就代表轉換失敗了？

但我把這個回答拿去問 Claude Code，它的反應是——「這個回答很可疑。」

它的推理很精彩：如果文字層真的存在，標準 PDF 閱讀器的 Ctrl+A 一定選得到，而我實測選不到。這兩件事矛盾。而矛盾的原因，很可能是那個 AI 誤判了自己的讀取方式——它是多模態模型，「看」PDF 有兩種管道，一種是真的解析文字層，一種是用視覺辨識畫面（本質就是 AI 版的 OCR），而它自己可能分不清楚用了哪一種。當它說「我直接讀取」，它可能其實是用看的。

然後它給了一個我認為是整個系列都通用的建議：

不要問 AI。改用不具備視覺能力的工具。

具體來說，是用 mutool draw -F txt 把 PDF 的文字層直接倒出來——這個工具沒有「視覺」，它只會照實報告 PDF 結構裡到底有沒有文字。輸出是空的，就代表文字層真的沒了；輸出有浮水印文字，才代表轉換沒生效。一個不會揣測、沒有視覺、只會照實回報的工具，才是這裡唯一可信的裁判。

這一天的分工：AI 產出，人負責找到「不會說謊的裁判」

把兩個案例擺在一起，結論很清楚。

AI 有它先天產不準的東西——畫不出台灣的輪廓、判斷不了浮水印指令到底有沒有生效。而且它產不準的時候不會自己舉手，它會給你一個聽起來很合理的答案（甚至附上比較表），讓你以為問題解決了。

人在這裡的價值，不是「比 AI 更會畫地圖」或「比 AI 更懂 PDF」，而是知道什麼時候不能相信它的說法，以及去哪裡找一個不會揣測的客觀依據：

• 地圖畫不準 → 去拿真實的 GML 圖資
• 浮水印判斷不了 → 用沒有視覺的 mutool draw 倒出文字層
• 連「驗證 AI」這件事，都不能用另一個 AI 去驗——要用一個不具判斷力、只會照實回報的工具

這就是為什麼我一直說，驗證這道關卡不能外包給 AI。它負責生成，人負責找到那個「不會說謊的裁判」來核對。少了這個裁判，AI 的四次自信，會讓你以為功能好了，直到出事。

明天換一個更戲劇性的事故：一個看起來人畜無害的設定，如何讓一個資料夾長出兩千多層、幾乎塞爆磁碟——而更精彩的是清理它的過程，AI 在旁邊連續估錯了五次，每一次都得靠我眼前的真實狀況把它拉回來。